More Jaguar hardware bugs, Fri Apr 8, 1994:

 - No proper score boarding on the divisor of a divide (so if you divide by the result of a long latency instruction you have problems).
 - The advertised fix to make GPU pause for the result of a long latency instruction DOES NOT WORK. Any two alu instructions, one immediately after another,
   which both write to the same register are unsafe - the result is just a rough mixture of bits from the two proper results, so it is not safe to use
   'or r0,r0' to wait for r0 to be ready because the result of 'or r0,r0' can get mixed up with the intended result of the instruction afterwards which
   is the one that you actually want; you can use 'cmpq #0,r0' instead (which reads r0 but does not write to it).
   As an example, try running the following at full speed on the GPU:
		movei	#-1,r0
		moveq	#0,r1
		or	r0,r0
		move	r1,r0
   and look at r0. This would give an unexpected result whatever the source of r0 before the 'or' instruction but it works fine if you use 'cmpq' instead.
 - The blitter cannot work in phrase mode in less then 8 bits per pixel (it appears that it starts running fine, but never exits the inner loop of the first
   line, so trashing memory and never stopping).
 - You can't write to the palette memory if either the blitter or the object processor is heavily loaded (some colours just don't get set or even get half
   set - set on odd pixels not even), so the best time to change palettes is in the vblank at a time when you know the blitter is not active.
 - I think I've reported this one, but the blitter doesn't work very well at all in 2 bit per pixel mode - I can't quite remember the details, but what
   happens, more or less, is that in a straight block transfer if the destination start x pixel is 0,1,4,5,8,9,etc. it works, but if it is 2,3,6,7,10,11,etc.
   then the o/p pixels are garbled
 - There is a VERY BIG, VERY NASTY bug with blitter clipping. If you ever use the clip function then the blitter no longer functions correctly (even
   with clip mode OFF) until you clear the A1_CLIP register. The bug is not obvious, but one or two pixels, at locations related to the value in the
   clip register, don't get transferred at all. If you can't reproduce this I can & will come up with some demo code. The fix is to ensure that for
   any blit that is not specifically using A1_CLIP, A1_CLIP MUST BE CLEAR. You can ensure this carefully by clearing it after use, or safely by clearing
   it before every blit.
 - Not fully checked out, but I don't think BKGWREN has any effect with CLIP_A1 in the blitter flags, i.e. there is no way to make the blitter write
   anything at all if A1 is clipped.

Mike @ Rebellion Software
